Agile coach or Scrum master illustration by Thea Schukken
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
Recently I looked at a number of hats an Experience Designer has to wear, thinking about other roles and fields that are involved within User Experience. Most recently I took a look at how User Experience involves some agile coaching. This time out I comment on the realisation of how closely design is related with architecture. It’s worth pointing out here that I specifically mean solution architecture. But appreciate it’s also closely related to the other form of architecture too!
Agile coach or Scrum master illustration by Thea Schukken
I recently heard a talk given by an Enterprise Architect Paul Fletcher around how Agile Architecture starts to address some of these challenges both our fields have been grappling with over a number of years and saw a lot of similarities. So thought I’d share some of the concepts and principals Paul discussed.
As useful background to the talk, here’s a couple of quotes from Paul:
Architects have always been agents and advocates of data driven, planned and sustainable change.
But Architecture (and design) need to adapt and evolve to ensure that it can serve the business for the long term.
Thinking of how Paul positioned Agile Architecture teams, it feels like they fit in the same place that Designers do. The grey area of ‘supporting’ or ‘servicing’ sprint teams. Not quite ‘part of sprint teams’, but not quite apart from them either. After all, we all need makers and engineers to bring our ideas to life.
Thinking about a sporting team, we would be the coaches or medical support staff. I know this is a hotly debated topic, so I’m sure of you will be open to debate on this, as would I, but for simplicity I’ve written this sporting analogy.
Often both architects and designers are talked about as being part of ‘sprint teams’ but then the ways of working in these teams don’t always support these disciplines.
We need time to fully understand a problem, so we can apply principals, guardrails and patterns to it. Which allows us to boil it down and simplify any challenges. This allows us to articulate these accurately to the wider audience of the ‘sprint teams’ and stakeholders.
To do this we need some time to think and explore ahead of supporting and servicing more detailed sprint work. As sprints are condensed periods of time, they don’t always allow this, as the delivery clock is always ticking. This can lead us to defining the wrong solutions and requiring rework, or totally missing the mark.
Don’t get me wrong I’m a pragmatist and 80% is good enough, so we don’t need to spend weeks upon weeks talking about architecture or design. We just need the time to understand and define problems. We can then rapidly diverge and converge on ideas. Particularly for design the challenge is finding time to test and learn from concepts hopefully before they’re built, if it’s more cost effective to do so.
This leaves both fields needing to structure themselves and work out how to feed into the agile way of working at a sprint level.
Sounds familiar right? It feels the words Architects and Designers are interchangeable at this point, and you’re able to see some of the key challenges that either field has in working in sprints.
Both fields are working to provide certainty to engineering teams so they’re able to make decisions on what to build and how to build it. Based on the knowledge that we know at any point in time. But in order to provide this certainty we need to be able to collaborate, have conversations and confirm concepts. The 3 C’s of agile. Read User Experience is ... providing certainty for more details on this.
Surveying and helping to find a path through the terrain ahead, so engineers can build roads, ports and runways etc. with speed and certainty.
There are some established approaches to this in the design field:
If you’re of an agile mindset though this isn’t BDUF (Big Design Up Front). It’s a way for other disciplines and fields to work with the sprint teams, in order to collaborate, hold sensible conversations and be able to confirm concepts by having opportunities to test and bringing ideas to refinement sessions, so these can be refined into sprint stories. It’s a way that we can work together and integrate a story work flow from inception through to delivery. Read User experience is … user story flow for more details on this.
Paul suggested 4 key concepts that Agile Architects can use to help guide the evolution and emergence of enterprise solutions from delivery teams:
If we look at these concepts from a design field point of view, you can see how we are already using some of these concepts:
This was the penny drop moment, when I realised that it’s not just the design field that finds it challenging to work in an agile way. But Architecture, Infrastructure and Security, are also grabbling with this in their own ways, and there are things we can share and learn from each other.
We are trusted to help guide teams so that they are able to make better decisions right where the work is being done
The evolutionary design of a Butterfly over time
Paul talks about a vision that evolves from learning. And the whole team should be on this learning journey. Product teams work better when they work together. So engineers have to be involved at this stage, after all it’s all about the conversation, collaboration and confirmation. 3 heads are always better than 1! And this isn’t the end, more like the beginning. At this point we’ve probably only developed enough certainty amongst the 3 amigos to feel comfortable and confident with the approach that we’re taking.
From here though we still need to evolve these ideas through refinement sessions with the wider engineering team to open it to new ideas and influences. Only after this will we be able to see ideas and solutions emerge from the approaches that each discipline have been able to guide and have a degree of comfort and confidence that they’ll be scalable.
We understand that our foundations (and vision) evolve as real world learnings emerge from “doing”
Evolution of humans over time
Guardrails, standards and patterns allow an emergent design to evolve.
Emergent design can come when teams are given a space to explore and evolve solutions in relative safety. Architects and Experience designers can guide teams following core principals and conventions, to enable any solutions that come out to be scalable and extensible. The 4 key concepts above (principals, guardrails, standards and patterns) enable emergent and evolutionary design from within sprint teams and colleagues that are right where the work is being done. Just as research and design principals, usability and accessibility standards and design patterns/systems, giving engineering teams the building blocks to start to be more autonomous and create working, shippable software, with more consultancy and less hand overs.
And I do mean guardrails not guide rails. This enables a safe space by preventing people from falling off the edge! Instead of being more restrictive and directing the direction of something which a guide rail might do.
We have principals, guardrails, standard and patterns
Paul outlines these Agile Architecture principals to follow to support teams:
The UX Design fields is a wash with principals from accessibility to typography. But looking at these principals outlined for Agile Architecture, we wouldn’t go far wrong if we kept to those!
Paul mentions emergent design, that allows the team to refine and mould concepts that have been tested and fit within the principals of both fields. This enables the shape of the product to emerge from the sprints over time.
These are the foundational components that support an emerging design. From an Architecture point of view this can be thought of as the services that are built out of products and used in other solutions. In the design field this can be thought of as design patterns that are explored and developed in a product but then applied to other use cases and built out as design patterns to be added to a design system.
These are signals from emergent design that evolution may need to happen. This can happen from outside an organisation or within. This raises the need to change the way that things are thought about or done either from another product that is being developed (internally) or from another industry (external). This can also be applied to bigger disruptions where experience or technology are rethought, leading to challenge and rethinking the way things are thought about or done.
Next up in the series I’ll be looking more into how we can work with our agile teams in order to learn as a team and not just earn story points from features or functionality that are built. This goes some way to start to answer how we could potentially work with engineering teams within a sprint.
Originally written as part of the ‘User Experience is …’ series for UX Collective.